fix(gui): Pace whole-screen fade loop through the frame pacer#2848
fix(gui): Pace whole-screen fade loop through the frame pacer#2848bobtista wants to merge 2 commits into
Conversation
|
Does this work properly? If your fps is 30, this would still sleep for 33 msec, right? That doesn't make sense to me if the menu transition speed is say 15. |
|
I tested this locally and it is waiting for completion of fade to black. I think frame pacing makes sense. |
Did you test with #2840 and e.g. a window transition speed of 15? EDIT: I'd expect it to work like this: |
|
No I tested with defaults only. |
6219f68 to
472a8c6
Compare
|
I tested with speed 1 and render fps 30 and 120, then again with speed 15 and render fps 30 and 120. The speed multiplier works and stays consistent across render speeds. |
I think that sleep(X) formula assumes the old model, fixed 1 frame per iteration, vary the sleep to control speed. The fade now advances a fixed number of transition-frames per real second regardless of frame rate eg at 120 fps it steps ~4× as often but ~4× smaller, and the total wall-clock duration matches 30 fps (just smoother). Duration is frameLength / BaseFps seconds. With #2840 the speed multiplier scales that already-time-normalized step, so speed 15 is 15× faster at any frame rate (frameLength / (BaseFps * speed)), independent of the wait. |
|
@Caball009 Are you OK with this change? |
Follow-up to #2840.
The whole-screen fade loop in
GameLogic::tryStartNewGamepaced itself with a hardcodedSleep(33). This froze the frame pacer for the duration of the fade, so the frame-rate-decoupled transition step from #2056 (getBaseOverUpdateFpsRatio()) read a stale delta and advanced at a fixed, frame-rate-dependent rate.This change replaces the delay with
TheFramePacer->update(), which caps the framerate and measures real elapsed time. The fade now advances at a consistent rate, and the magic 33 ms delay is gone now that transition speed is variable.Todo